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(54) MOBILE TERMINAL AND DATA TRANSMISSION SYSTEM 

(57) There is provided a mobile terminal such as a 
portable telephone set equipped with relatively small 
data memory and a data transmission scheme adapted 
to receive PUSH messages provided by the information 
source at an arbitrary timing without fail. The message 
request processing means (1 04), based on the descrip- 
tion on messages contained in the incoming notice 
received by the data transmitting/receiving means 
(1 01 ), checks whether available memory is present or 
not in the message save means (103), and in case it is 
present, makes a message acquisition request to the 
Web protocol processing means (102). The message 
analysis processing means (105) analyzes messages 
returned from the server unit. The message managing 
means (106) saves the analyzed messages in the mes- 
sage save means (1 03). When an inquiry is made about 
whether the message memory is available or not, the 
message managing means (106) checks for available 
memory in the message save means (1 03) and notifies 
the result of the check for available memory to the mes- 
sage request processing means (104). 
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Description 

Technical Field 

[0001 ] The present invention relates to a mobile ter- 5 
minal and a data transmission scheme, and more par- 
ticularly, to a mobile terminal and a data transmission 
scheme adapted to allow PUSH messages to be deliv- 
ered from a server to a client (the mobile terminal) 
equipped with small data memory. w 

Background Art 

[0002] In information communications in the 
advanced information-oriented society today, users can 15 
acquire a variety of information on demand by specify- 
ing the destination address on the Internet. 
[0003] As a data transfer protocol between a server 
and a client, the HTTP (Hypertext Transfer Protocol) is 
in widespread use. zo 
[0004] By using the HTTP, the server responds to 
the client's request for information and notifies the user 
of the target information, allowing the user to acquire 
such information. 

[0005] In recent years, not only PULL services 25 
where a client activates a request but also PUSH serv- 
ices where the information source provides the client 
with information at an arbitrary timing. 
[0006] This allows information to be provided to 
users from a predetermined information source without 30 
the client having to activate the information sending 
request. 

[0007] For example, in the "A data broadcast sys- 
tem and a terminal thereof disclosed in JP-A-9- 
148994, a variety of digital signals are transmitted via 35 
broadcast data channels and a receiver to receive 
broadcast data can acquire information in real time. 
[0008] However, for a mobile terminal whose data 
memory is relatively small, a problem occurs that the 
mobile terminal cannot save all the information provided 40 
from the information source. This loss in information is a 
problem in the case of important information such as 
paid service information and mails. 
[0009] In view of the foregoing problem, the inven- 
tion aims at providing a mobile terminal equipped with 45 
small data memory and a data transmission scheme 
which can receive real-time information provided by an 
information source without fail. 

Disclosure of the Invention so 

[001 0] In order to solve the problem, a mobile termi- 
nal according to the invention is a mobile terminal which 
receives an incoming notice, characterized in that the 
mobile terminal, triggered by signals contained in the 55 
incoming notice showing the presence of a delivery 
message in a server, makes a request for acquiring the 
delivery message, and receives the delivery message 



transmitted from the server based on the delivery mes- 
sage acquisition request. 

[001 1] In orderto solve the problem, a mobile termi- 
nal according to the invention is characterized in that the 
incoming notice contains a delivery message type 
showing the major classification of the delivery mes- 
sage, and that the mobile terminal makes a delivery 
message acquisition request to the server based on the 
delivery message type. 

[0012] Further, in order to solve the problem, a 
mobile terminal according to the invention is character- 
ized in that the mobile terminal checks whether the 
mobile terminal can reserve a delivery message save 
area or not before making the delivery message acqui- 
sition request based on the incoming notice, and that, in 
case the delivery message save area can be reserved, 
the mobile terminal makes the delivery message acqui- 
sition request. 

[0013] Further, in order to solve the problem, a 
mobile terminal according to the invention is character- 
ized in that the mobile terminal determines that, in case 
delivery messages saved in the mobile terminal have 
been read and are not protected, they can be overwrit- 
ten by a new incoming delivery message and deter- 
mines that the save area can be reserved in a decision 
whether the delivery message save area can be 
reserved or not. 

[0014] Further, in order to solve the problem, a 
mobile terminal according to the invention is character- 
ized in that the delivery message type may be a mail. 
[001 5] Further, in order to solve the problem, a data 
transmission scheme according to the invention 
whereby a mobile terminal and a server unit performs 
data transmission via a network is characterized in that, 
when the mobile terminal returns a response indicating 
that the mobile terminal has received delivery mes- 
sages transmitted from the server, the server deletes 
the stored messages. 

Brief Description of the Drawings 

[0016] 

Fig. 1 shows the configuration of a receiver accord- 
ing to the embodiment of the invention. 
Fig. 2 is a first flowchart showing the flow of PUSH 
message acquisition processing by the receiver 
according to the embodiment of the invention. 
Rg. 3 is a second flowchart showing the flow of 
PUSH message acquisition processing by the 
receiver according to the embodiment of the inven- 
tion. 

Rg. 4 is a third flowchart showing the flow of PUSH 
message acquisition processing by the receiver 
according to the embodiment of the invention. 
Rg. 5 shows an example of a PUSH message 
incoming notice according to the embodiment of the 
invention. 
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Fig. 6 shows an example of a PUSH message 
acquisition request message according to the 
embodiment of the invention. 
Fig. 7 shows an example of a first PUSH message 
acquired by a receiving terminal according to the s 
embodiment of the invention. 
Fig. 8 shows an example of a second PUSH mes- 
sage acquired by a receiving terminal according to 
the embodiment of the invention. 
Fig. 9 is a sequence diagram showing the process- w 
ing made between a receiving terminal and a 
server unit during data transmission made by the 
mobile terminal and the server via a network. 

Best Mode for Carrying Out the Invention is 

[0017] The embodiment of the invention will be 
detailed below with reference to attached drawings. 
[0018] Fig. 1 shows the configuration of a mobile 
terminal (receiver) according to the embodiment of the 20 
invention. 

[0019] In Fig. 1 , a receiver 1 as a mobile terminal is 
composed of a data transmitting/receiving means 1 01 
for performing data transmission/reception in a portable 
telephone network, a Web protocol processing means 25 
1 02 for processing the HTTP which is a Web protocol 
used to acquire contents messages stored in a server 
unit between the receiver and the server unit, a PUSH 
message save means 1 03 for saving PUSH messages 
received by the receiver 1 , a PUSH message request 30 
processing means 104, a PUSH message analysis 
processing means 1 05, and a PUSH message manag- 
ing means 1 06. 

[0020] The PUSH message request processing 
means 104, based on the description on PUSH mes- 35 
sages contained in the incoming notice received by the 
data transmitting/receiving means 101, checks whether 
available area is present or not in the PUSH message 
save means 103, and in case it is present, the PUSH 
message request processing means 104 makes a 40 
PUSH message acquisition request to the Web protocol 
processing means 102. 

[0021] The PUSH message analysis processing 
means 105, in response to the PUSH message acquisi- 
tion request made to the information source server by 45 
the PUSH message request processing means 104, 
performs analysis processing of PUSH messages 
returned from the server. 

[0022] The PUSH message managing means 106 
saves PUSH messages analyzed by the PUSH mes- 50 
sage analysis processing means 105 in the PUSH mes- 
sage save means 103. The PUSH message managing 
means 106, on receiving an inquiry from the PUSH 
message request processing means 104 about whether 
available area is present or not in the PUSH message 55 
memory, checks whether available area is present or 
not in the PUSH message save means 103 and notifies 
the PUSH message request processing means 104 of 



the presence or absence of available area. 
[0023] Figs. 2 through 4 are flowcharts showing the 
flow of PUSH message acquisition processing by the 
receiver according to the embodiment of the invention. 
The following describes the flow of PUSH message 
acquisition processing after the data transmit- 
ting/receiving means 1 01 of the receiver 1 in Fig. 1 has 
received a PUSH message incoming notice: 
[0024] Step 101 : The PUSH message request 
processing means 104 checks the PUSH message type 
information contained in the PUSH message incoming 
notice transmitted from the data transmitting/receiving 
means 101. In case the PUSH message type informa- 
tion contains mails, execution proceeds to step 102. 
Otherwise, execution proceeds to step 201 in Fig. 3. 
[0025] Step 102 : The PUSH message request 
processing means 104 makes an inquiry about pres- 
ence or absence of the available mail memory to the 
PUSH message managing means 106. The PUSH 
message managing means 106 checks for available 
mail memory in the PUSH message save means 103, 
and notifies the result of the check for available mail 
memory. In case available area is present in the mail 
memory, execution proceeds to step 103. Otherwise, 
execution proceeds to step 201 in Fig. 3. 
[0026] Step 103 : The PUSH message request 
processing means 104 makes an mail acquisition 
request to the Web protocol processing means 102. 
The Web protocol processing means 102, based on a 
request from the PUSH message request processing 
means 104, creates mail acquisition request data in 
HTTP format negotiated with the server, then asks the 
data transmitting/receiving means 101 to send the data. 
The data transmitting/receiving means 101 sends the 
data asked by the Web protocol processing means 1 02 
to the server unit, and execution proceeds to step 104. 
[0027] Step 104 : The data transmitting/receiving 
means 101 , on receiving the data from the server, noti- 
fies the received data to the Web protocol processing 
means 1 02. The Web protocol processing means 1 02, 
on receiving the PUSH messages transmitted from the 
server unit in accordance with the HTTP format, notifies 
completion of receiving the PUSH messages to the 
PUSH message analysis processing means 105. In 
case the PUSH message analysis processing means 
1 05, based on the PUSH message receiving completion 
notice from the Web protocol processing means 1 02, 
has successfully acquired the mails, execution pro- 
ceeds to step 105. Otherwise, execution proceeds to 
step 201 in Fig. 3. 

[0028] Step 1 05 : The PUSH message managing 
means 106, based on the request from the PUSH mes- 
sage analysis processing means 105, saves the 
received mails in the mail memory in the PUSH mes- 
sage save means 1 03. Execution then proceeds to step 
106. 

[0029] Step 106 : The PUSH message analysis 
processing means 105, based on the information about 
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presence or absence of non-acquired mails contained 
in the received PUSH messages in the server. In case 
non -acquired mails are present in the server, execution 
proceeds to step 1 02. Otherwise, execution proceeds to 
step 201 in Fig. 3. 

[0030] Hereinafter, processing for acquiring PUSH 
messages in accordance with the flowchart in Fig. 3 will 
be described. 

[0031] Step 201 : The PUSH message request 
processing means 1 04 checks the PUSH message type 
information contained in the PUSH message incoming 
notice transmitted from the data transmitting/receiving 
means 101. In case the PUSH message type informa- 
tion contains the first information service message, exe- 
cution proceeds to step 202. Otherwise, execution 
proceeds to step 301 in Fig. 4. 

[0032] Step 202 : The PUSH message request 
processing means 104 makes an inquiry about pres- 
ence or absence of the available area in the memory for 
the first information service message to the PUSH mes- 
sage managing means 1 06. The PUSH message man- 
aging means 106 checks for available area in the 
memory of the PUSH message save means 103 for the 
first information service message, and notifies the result 
of the check for available memory. In case available 
memory is present in the memory for the first informa- 
tion service message , execution proceeds to step 203. 
Otherwise, execution proceeds to step 301 in Fig. 4. 
[0033] Step 203 : The PUSH message request 
processing means 1 04 makes a first information service 
message acquisition request to the Web protocol 
processing means 102. The Web protocol processing 
means 102, based on a request from the PUSH mes- 
sage request processing means 104, creates the first 
information service message acquisition request data in 
HTTP format negotiated with the server, then asks the 
data transmitting/receiving means 1 01 to send the data. 
The data transmitting/receiving means 1 01 sends the 
data asked by the Web protocol processing means 1 02 
to the server unit, and execution proceeds to step 204. 
[0034] Step 204 : The data transmitting/receiving 
means 1 01 , on receiving the data from the server, noti- 
fies the received data to the Web protocol processing 
means 102. The Web protocol processing means 102, 
on receiving the PUSH messages transmitted from the 
server in accordance with the HTTP format, notifies 
completion of receiving the PUSH messages to the 
PUSH message analysis processing means 105. In 
case the PUSH message analysis processing means 
1 05, based on the PUSH message receiving completion 
notice from the Web protocol processing means 102, 
has successfully acquired the first information service 
message, execution proceeds to step 205. Otherwise, 
execution proceeds to step 301 in Fig. 4. 
[0035] Step 205 : The PUSH message managing 
means 106, based on the request from the PUSH mes- 
sage analysis processing means 105, saves the 
received first information service message in the mem- 



ory for the first information service message in the 
PUSH message save means 103. Execution then pro- 
ceeds to step 206. 

[0036] Step 206 : The PUSH message analysis 

5 processing means 105, based on the contents type 
information contained in the received PUSH message, 
checks whether the text of the received PUSH message 
is written in the HTML (Hypertext Markup Language). In 
case the text of the received PUSH message is written 
10 in the HTML, execution proceeds to step 207. Other- 
wise, execution proceeds to step 21 0. 
[0037] Step 207 : The PUSH message analysis 
processing means 105 checks whether in-line image 
information is detected indicating that image data is 

15 inserted in the HTML contents and whether a request 
for acquiring the image data indicated in the in-line 
image information has not been made. In case such a 
request has not been made, execution proceeds to step 
208. Otherwise, execution proceeds to step 210. 

20 [0038] Step 208 : The PUSH message analysis 
processing means 105 notifies the PUSH message 
request processing means 1 04 that the HTML contents 
received from the server unit contains non-acquired 
image data. The PUSH message request processing 

25 means 104 makes a non-acquired image data acquisi- 
tion request to the Web protocol processing means 1 02. 
The Web protocol processing means 102, based on a 
request from the PUSH message request processing 
means 104, creates the acquisition request data in 

30 HTTP format negotiated with the server, then asks the 
data transmitting/receiving means 101 to send the data. 
The data transmitting/receiving means 101 sends the 
data asked by the Web protocol processing means 102 
to the server unit, and execution proceeds to step 209. 

35 [0039] Step 209 : The data transmitting/receiving 
means 101, on receiving the data from the server unit, 
notifies the received data to the Web protocol process- 
ing means 102. The Web protocol processing means 
1 02, on receiving the PUSH messages transmitted from 

40 the server in accordance with the HTTP format, notifies 
completion of receiving the PUSH messages to the 
PUSH message analysis processing means 105. In 
case the PUSH message analysis processing means 
1 05, based on the PUSH message receiving completion 

45 notice from the Web protocol processing means 102, 
has successfully acquired the in-line image information, 
the PUSH message analysis processing means 105 
saves the image data information. Execution then pro- 
ceeds to step 207. Otherwise, the PUSH message anai- 

so ysis processing means 1 05 skips saving the image data 
information. Execution then proceeds to step 207. 
[0040] Step 210 The PUSH message analysis 
processing means 105, based on the information about 
presence or absence of non-acquired first information 

55 service message contained in the received PUSH mes- 
sages in the server. In case non-acquired first informa- 
tion service message is present in the server, execution 
proceeds to step 202. Otherwise, execution proceeds to 
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step 301 in Fig. 4. 

[0041] Hereinafter, processing for acquiring PUSH 
messages in accordance with the flowchart in Fig. 4 will 
be described. 

[0042] Step 301 : The PUSH message request 5 
processing means 1 04 checks the PUSH message type 
information contained in the PUSH message incoming 
notice transmitted from the data transmitting/receiving 
means 101. In case the PUSH message type informa- 
tion contains the second information service message, 10 
execution proceeds to step 302. Otherwise, execution 
terminates. 

[0043] Step 302 The PUSH message request 
processing means 104 makes an inquiry about pres- 
ence or absence of the available area in the memory for 15 
the second information service message to the PUSH 
message managing means 106. The PUSH message 
managing means 106 checks for available area in the 
memory of the PUSH message save means 1 03 for the 
second information service message, and notifies the 20 
result of the check for available memory. In case availa- 
ble memory is present in the memory for the second 
information service message , execution proceeds to 
step 303. Otherwise, execution terminates. 
[0044] Step 303 : The PUSH message request 25 
processing means 104 makes a second information 
service message acquisition request to the Web proto- 
col processing means 102. The Web protocol process- 
ing means 102, based on a request from the PUSH 
message request processing means 104, creates the 30 
second information service message acquisition 
request data in HTTP format negotiated with the server, 
then asks the data transmitting/receiving means 101 to 
send the data. The data transmitting/receiving means 
1 01 sends the data asked by the Web protocol process- 35 
ing means 1 02 to the server unit, and execution pro- 
ceeds to step 304. 

[0045] Step 304 : The data transmitting/receiving 
means 101, on receiving the data from the server unit, 
notifies the received data to the Web protocol process- 40 
ing means 102. The Web protocol processing means 
102, on receiving the PUSH messages transmitted from 
the server in accordance with the HTTP format, notifies 
completion of receiving the PUSH messages to the 
PUSH message analysis processing means 105. In 45 
case the PUSH message analysis processing means 
105, based on the PUSH message receiving completion 
notice from the Web protocol processing means 1 02, 
has successfully acquired the second information serv- 
ice message, execution proceeds to step 305. Other- so 
wise, execution terminates. 

[0046] Step 305 : The PUSH message managing 
means 1 06, based on the request from the PUSH mes- 
sage analysis processing means 105, saves the 
received second information service message in the 55 
memory in the PUSH message save means 103 for the 
second information service message. Execution then 
proceeds to step 306. 



[0047] Step 306 : The PUSH message analysis 
processing means 105, based on the contents type 
information contained in the received PUSH message, 
checks whether the text of the received PUSH message 
is written in the HTML (Hypertext Markup Language). In 
case the text of the received PUSH message is written 
in the HTML, execution proceeds to step 307. Other- 
wise, execution proceeds to step 310. 
[0048] Step 307 : The PUSH message analysis 
processing means 105 checks whether in-line image 
information is detected indicating that image data is 
inserted in the HTML contents and whether a request 
for acquiring the image data indicated in the in-line 
image information has not been made. In case such a 
request has not been made, execution proceeds to step 
308. Otherwise, execution proceeds to step 310. 
[0049] Step 308 : The PUSH message analysis 
processing means 105 notifies the PUSH message 
request processing means 1 04 that the HTML contents 
received from the server unit contains non-acquired 
image data. The PUSH message request processing 
means 104 makes a non-acquired image data acquisi- 
tion request to the Web protocol processing means 1 02. 
The Web protocol processing means 102, based on a 
request from the PUSH message request processing 
means 104, creates the acquisition request data in 
HTTP format negotiated with the server, then asks the 
data transmitting/receiving means 101 to send the data. 
The data transmitting/receiving means 101 sends the 
data asked by the Web protocol processing means 1 02 
to the server unit, and execution proceeds to step 309. 
[0050] Step 309 : The data transmitting/receiving 
means 101, on receiving the data from the server unit, 
notifies the received data to the Web protocol process- 
ing means 102. The Web protocol processing means 
1 02, on receiving the PUSH messages transmitted from 
the server in accordance with the HTTP format, notifies 
completion of receiving the PUSH messages to the 
PUSH message analysis processing means 105. In 
case the PUSH message analysis processing means 
1 05, based on the PUSH message receiving completion 
notice from the Web protocol processing means 102, 
has successfully acquired the in-line image information, 
the PUSH message analysis processing means 105 
saves the image data information. Execution then pro- 
ceeds to step 307. Otherwise, the PUSH message anal- 
ysis processing means 1 05 skips saving the image data 
information. Execution then proceeds to step 307. 
[0051] Step 310 : The PUSH message analysis 
processing means 105, based on the information about 
presence or absence of non-acquired second informa- 
tion service message contained in the received PUSH 
messages in the server, checks for non-acquired sec- 
ond information service messages contained in the 
received PUSH message in the server. In case non- 
acquired second information service messages are 
present in the server, execution proceeds to step 302. 
Otherwise, execution terminates. 
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[0052] A particular operation of the receiver 1 which 
operates as mentioned earlier assumed when the 
receiver has received the PUSH message incoming 
notice in Fig. 5 will be described below. 
[0053] Fig. 5 shows an example of information on a 
PUSH message contained in the PUSH message 
incoming notice according to the embodiment of the 
invention. 

[0054] The PUSH message notice incoming notice 
is composed of PUSH message type information indi- 
cating the classification of PUSH messages, and server 
storage capacity information indicating whether PUSH 
message storage area is full or not in the server unit. 
[0055] Types of PUSH messages in this embodi- 
ment comprise mail, first information service message, 
and second information service message. "1 M indicates 
that non-acquired PUSH message is present in the 
server. "0" indicates that non-acquired PUSH message 
is absent in the server. 

[0056] Now that the PUSH message type informa- 
tion is "0001", on-acquired data in the server unit is mail 
data only. 

[0057] The PUSH message storage capacity infor- 
mation is accessory information to each PUSH mes- 
sage type. "1" indicates that the PUSH message 
storage capacity in the server is full. 
[0058] Now that the PUSH message type informa- 
tion is "0000", the PUSH message storage capacity in 
the server is not full. 

[0059] In case the data transmitting/receiving 
means 101 has received information on PUSH mes- 
sages contained in the PUSH message incoming notice 
shown in Fig. 5, the information is notified to the PUSH 
message request processing means 104. The PUSH 
message request processing means 104 analyzes the 
description in the PUSH message incoming notice and 
determines that the server contains non-acquired mails 
(see step 101). 

[0060] The PUSH message request processing 
means 104 makes an inquiry about whether available 
area is present in the mail memory or not to the PUSH 
message managing means 106. The PUSH message 
managing means 1 06 checks for available mail memory. 
In case the mail memory in the PUSH message save 
means 1 03 is full of mails which have already been read 
and are unprotected, the mails can be overwritten and 
the memory is assumed to be available. In case the mail 
memory is available, a mail acquisition request is made 
(see step 103). 

[0061] A particular example of the PUSH message 
(mail) acquisition request message is shown in Fig. 6. 
The PUSH message acquisition request message is 
configured in accordance with the HTTP request mes- 
sage. The HTTP request message is composed of a 
method to indicate the processing request details, URL 
information to locate the destination and HTTP version 
information. 

[0062] In the PUSH message (mail) acquisition 



request message in Fig. 6, the method to indicate the 
processing request details is "GET", which indicates a 
contents acquisition request. The URL information con- 
tains the destination address, PUSH message type and 

5 acquisition request PUSH message ID. The PUSH mes- 
sage type "e_mes" indicates that the PUSH message 
as an object of acquisition request is a mail. The acqui- 
sition request PUSH message ID is represented in five 
digits following "NXT=". Note that "00000" is an ID indi- 

10 eating start of a PUSH message acquisition request. 
"HTTP/1 .0" indicates that the HTTP version is 1 .0. 
[0063] Fig. 7 shows a first particular example of the 
PUSH message acquired from a server conforming to 
the HTTP response format. 

75 [0064] HTTP response data is composed of a 
response line, header, and body which corresponds to a 
text. The first line is a response line and composed of 
HTTP version information, status code of processing 
results on the request, and explanation on the status 

20 code. 

[0065] In the example shown in Fig. 7, the HTTP 
version is 1 .0, as understood from "HTTP/1 .0". The sta- 
tus code "200", indicating that the request has been 
accepted by the server and text data is valid data for the 
25 request. "OK" is an explanation of the status code. 
[0066] From the second line to the vacant line indi- 
cated by <CRxLF)(0x0D,0x0A) correspond to header. 
"Content-Length" indicates the number of bytes of the 
text data. 

30 [0067] "Content-Type" indicates the contents type 
of the text data, "text/plain" indicates a plain text. 
Header information starting with "X-" is header informa- 
tion expanded to acquire PUSH messages. 
[0068] "X-EID" indicates the mail ID. The first half 

35 "00001" indicates the ID of the mail as acquired text 
data. The second half "00002" indicates the mail ID 
used to make an E-mail acquisition request next time. 
[0069] "X-D" is date information and indicates the 
time when a PUSH message arrived at the server. 

40 "1 9981 21 71 639" indicates December 1 7, 1 6:39, 1 998. 
[0070] "X-F" indicates the source mail address 
[0071] Fig. 8 shows a second particular example of 
the PUSH message acquired from a server. Same as 
the first specific example, the PUSH message conforms 

45 to the HTTP response format. "X-EID" which is header 
information expanded to acquire PUSH messages indi- 
cates a mail ID. The first half "00002" indicates the ID of 
mail which is acquired text data. The second half indi- 
cates the mail ID used to make an E-mail acquisition 

so request next time. In Fig. 8, the second half is "00000", 
indicating that the server unit does not store any non- 
acquired mails. 

[0072] Fig. 9 is a sequence diagram showing the 
processing made between a receiving terminal and a 
55 server unit during data transmission made by the mobile 
terminal and the server unit via a network. This example 
shows a case where two mails destined for a receiver 1 
are stored in the server unit. 
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[0073] The server assigns the mail IDs of two mails 
to 00001 and 00002 respectively. The server transmits a 
PUSH message incoming notice in order to notify the 
receiver 1 that non-acquired PUSH messages (mails) 
are stored in the receiver 1 . Shown in the figure is a 5 
case where the PUSH message incoming notice is 
transmitted to the receiver 1 . 

[0074] In the receiver 1 , based on the PUSH mes- 
sage incoming notice received via the data transmit- 
ting/receiving means 101 shown in Fig. 5, the PUSH 10 
message request processing means 104 sees the 
PUSH message type information mail as "1 " and deter- 
mines that non-acquired mails are stored in the server, 
then makes an inquiry about present or absence of 
available memory for acquisition of mails to the PUSH 15 
message managing means 106. Here, it is assumed 
that available memory for acquisition of mails is present 
in the PUSH message save means 1 03. 
[0075] Because available memory for acquisition of 
mails can be reserved, the PUSH message request 20 
processing means 1 04 transmits to the server a PUSH 
message (mail) acquisition start request (see step 1 03). 
[0076] The server unit, on receiving the PUSH mes- 
sage (mail) acquisition start request, transmits the first 
mail as a PUSH message shown in Fig. 7 to the receiver 25 
1. 

[0077] M X-EID:00001/00002" indicates that the first 
mail transmitted from the server unit to the receiver 1 
corresponds to the mail having the mail ID "00001" 
stored in the server. 30 
[0078] The second half "00002" is instruction infor- 
mation which indicates that non-transmitted mails are 
stored in the server unit, and instructs that the ID 
"00002" be used for a PUSH message (mail) acquisition 
request made by the receiver 1 . 35 
[0079] The receiving terminal, on receiving a PUSH 
message (mail) acquisition response, saves the 
received mails in the mail memory reserved in the 
PUSH message save means 1 03 (see step 1 05). 
[0080] The receiver 1, on receiving the data trans- 40 
mitted from the server unit, transmits a data receiving 
completion response to the server unit via the data 
transmitting/receiving means 101. 
[0081] The server, on receiving the data receiving 
completion response from the receiver 1 , assumes that 45 
mail transmission to the receiver 1 is complete and 
deletes the mail having the mail iD "00001" in the mail 
box. 

[0082] The receiver 1 , checking that the mail ID to 
be requested next contained in the PUSH message so 
(mail) acquisition response is other than "00000", deter- 
mines that non-acquired mails are stored in the server 
unit (see step 1 06). To acquire mails again, a check is 
made to determine whether mail memory is available or 
not. In this case also, it is assumed that available mem- 55 
ory is present in the PUSH message save means 1 03. 
[0083] The receiver 1 transmits the PUSH message 
(mail) acquisition request "NXT=00002" to the server 



unit. The server unit, receiving the PUSH message 
(mail) acquisition request, transmits the mail having the 
mail ID: 00002 stored in the mail box to the receiver 1 as 
a PUSH message shown in Fig. 8. 
[0084] In doing so, the mail box on the server does 
not store any non-transmitted mails. Thus transmission 
is made assuming the mail ID information as "X-EID: 
00002/00000". 

[0085] "00002" is the mail ID of the mail text being 
transmitted and the second half "00000" indicates that 
the server unit does not store any non-transmitted 
mails. 

[0086] The receiver 1, on receiving the data trans- 
mitted from the server unit, transmits a data receiving 
completion response to the server via the data transmit- 
ting/receiving means 101. 

[0087] The server, on receiving the data receiving 
completion request from the receiver 1, assumes that 
mail transmission to the receiver 1 is complete and 
deletes the mail having the mail ID "00002" in the mail 
box. 

[0088] While in the embodiment, in determining 
whether the PUSH message memory is available or not 
by the PUSH message managing means 106, PUSH 
messages which have already been read and are 
unprotected can be overwritten and the memory is 
assumed to be available, overwriting can be disabled 
unless PUSH messages are deleted via user operation. 

Industrial Applicability 

[0089] Thus, according to the invention, it is possi- 
ble to provide a mobile terminal such as a portable tele- 
phone set equipped with relatively small data memory 
and a data transmission scheme adapted to receive 
PUSH messages provided by the information source at 
an arbitrary timing without fail. 

Claims 

1. A mobile terminal which receives an incoming 
notice, characterized in that said mobile terminal, 
triggered by signals contained in said incoming 
notice showing the presence of a delivery message 
destined for said mobile terminal in a server unit, 
makes a request for acquiring said delivery mes- 
sage, and receives said delivery message transmit- 
ted from said server unit based on said delivery 
message acquisition request. 

2. A mobile terminal according to claim 1, character- 
ized in that said incoming notice contains a delivery 
message type showing a major classification of 
said delivery message, and that said mobile termi- 
nal makes a delivery message acquisition request 
to said server unit based on said delivery message 
type. 
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3. A mobile terminal according to claim 1 , character- 
ized in that said mobile terminal checks whether 
said mobile terminal can reserve a delivery mes- 
sage save area or not before making said delivery 
message acquisition request based on said incom- 5 
ing notice, and that, in case the delivery message 
save area can be reserved, said mobile terminal 
makes said delivery message acquisition request. 

4. A mobile terminal according to claim 3, character- 
ized in that said mobile terminal determines that, in 
case delivery messages saved in said mobile termi- 
nal have been read and are not protected, they can 
be overwritten by a new incoming delivery message 
and determines that the save area can be reserved 
in a decision whether the delivery message save 
area can be reserved or not. 

5. A mobile terminal according to claim 2, character- 
ized in that said delivery message type may be a 20 
mail. 

6. A data transmission scheme whereby a mobile ter- 
minal and a server unit performs data transmission 

via a network, characterized in that, when said 25 
mobile terminal returns a response indicating that 
said mobile terminal has received delivery mes- 
sages transmitted from said server unit, said server 
unit deletes the stored messages. 
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FIG. 5 
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FIG. 7 
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FIG. 9 
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